\chapter{Komunikace s DB}
% datasety, Linq2sql, Entity framework..
Jednou z klíčových věcí každé aplikace je ukládání rozpracovaných dokumentů. Tuto funkcionalitu lze zajistit několika možnými způsoby, záleží na způsobu použití těchto dat. Osobně preferuji ukládání dat do lokálních databází, které za nás řeší problémy konzistence a umožňují programátorům soustředit se pouze na klíčové problémy. 

Pokud má program spolupracovat s jinými aplikacemi, je vhodné vytvořit funkce pro export či import. Ideální je nepoužívat binární ukládání, protože od tohoto způsobu se v dnešní době upouští. Příkladem může být balík programů Microsoft Windows Office od verze 2007 a vyšší.
Při exportu a importu se preferují buď zavedené formáty, nebo využítí značkovacího jazyka XML.

Pro desktopové aplikace, u kterých je naplánován provoz bez nutnosti internetového připojení, je vhodné využít některé z lokálních databází. Příkladem může být produkt SQLLite či odlehčená verze Microsoft SQL databáze, často označovaná jako SQL Compact Edition.

\section{Datasety}
Jedním z nejstarších přístupů, avšak dodnes využívaných, jsou datasety. Pomocí množství podpůrných objetků, jako jsou například SqlCommandy, SqlDataReader a mnoho dalších, se dostává programátorům do rukou mocný nástroj pro relativně přímý přístup do databáze. Relativně proto, že vše jde přes perzistentní vrstvu v paměti, která urychluje čtení, umožňuje provést mnoho změn najednou a promítnout vše do databáze.

Práce s datasety znamená velikou režii navíc, ale výhodou pak je, že má programátor veškerý kód pod svojí kontrolou, což se u použití ORM mapperu říci nedá.

Bohužel datasety ve spolupráci s MS SQL Compact Edition trpí jistými nedostatky:

\begin{itemize}
	\item problémy s návratovými hodnotami (MS SQL CE neumí skládání dotazů)
	\item nemožnost lazy loadingu
	\item vyšší režie
\end{itemize}

Výhodou je pak nejvyšší výkon ze všech dostupných technologií.

\section{Linq2SQL} \label{sec:linq}
% ROZSAH < 1/2
S vydáním .net frameworku 3.5 přichází Microsoft s novým integrovaným dotazovacím jazykem \textbf{Linq}. Tento jazyk je psán dostatečně obecně a lze je aplikovat na kolekce, slovníky, xml i databáze. 
Právě poslední zmíněná komunikace s databází byla zpočátku omezena pouze na produkty od Microsoftu, tedy klasickou serverovou databázi a již zmiňovanou kompaktní verzi. Přímo v kódu lze pak skládat dotazy s komfortem samotného Visual Studia či jiného programovacího prostředí (zkráceně IDE) a samotný SQL dotaz je pak složen na pozadí.

\subsubsection{Výhody}
\begin{itemize}
	\item komfort IDE
	\item lazy loading
	\item možnost urychlení pomocí kompilace dotazů
	\item odstraňuje problémy se skládání dotazů
\end{itemize}

\subsubsection{Nevýhody}
\begin{itemize}
	\item omezenost na produkty od Microsoftu
	\item prográmator nemá ,,pod kontrolu'' samotné SQL dotazy
	\item vazby N:M (není to klasický ORM Mapper)
\end{itemize}

\textit{Linq2SQL} znamená odlehčení práce pro programátory, ale tato výhoda s~sebou nese samozřejmě jistou režii, a tak je na tom výkonově tato technologie v porovnání s datasety hůře. Pokles výkonu je ale velice nepatrný.

Protože \textit{Linq2SQL} není klasickým ORM mapperem, jeho největší nevýhodou je, že si neumí poradit s vazbami N:M a tak tato práce zůstává na samotném programátorovi.

\section{Entity framework}
Microsoft si byl velice vědom nevýhod technologie \textit{Linq2SQL} a tak hned v~následujícím service packu 1 vydal nový produkt, Entity framework (zkráceně EF), který je plnohodnotným ORM mapperem. Tato technologie odstraňuje problém s omezením na MS SQL databáze a vazbami M:N. 

Entity framework se stal nástupcem \textit{Linq2SQL} a Microsoft se již nadále vývojem této technologie (\textit{Linq2SQL}) nezabývá. Přístup do databáze je rovněž poskytován za pomoci dotazovacího jazyku \textbf{LINQ}.

\subsubsection{Výhody}
\begin{itemize}
	\item komfort IDE
	\item lazy loading
	\item možnost urychlení pomocí kompilace dotazů
	\item odstraňuje problémy se skládání dotazů
	\item vazby N:M
	\item plnohodnotný ORM mapper
	\item použitelný pro většinu bězných databází
\end{itemize}

\subsubsection{Nevýhody}
\begin{itemize}
	\item komfort si vybírá daň na výkonu
	\item prográmator nemá ,,pod kontrolu'' samotné SQL dotazy
\end{itemize}

Mezi programátory využívající ORM mappery a ostatními, využívající klasický přístup přes datasety či přímý přístup přes Stored procedury existuje odvěká rivalita a obě dvě strany se nemohou shodnout, který způsob je ten jediný správný. ORM mappery usnadňují práci s databázemi a odstíňují programátora od přímé znalosti databáze či T-SQL jazyka. Programátor tak nemusí znát více jazyků a může se soustředit na jeden hlavní. Druhá strana věci je však to, že programátor nemá vliv na výsledný SQL dotaz, což u~některých typů aplikací může být velice důležité. 

Osobně si myslím, že oba přístupy mají své místo a záleží ryze na typu aplikace.